Intent-driven functional verification of digital designs

ABSTRACT

Method and apparatus are provided for facilitating analysis of the intended behavior of a hardware design. According to one embodiment of the present invention, a language-based representation of a hardware design is received. Multiple design verification checks are generated for use in connection with model checking by applying a set of one or more predetermined properties to the language-based representation of the hardware design. Then, the hardware design, as implemented according to the language-based representation, is verified against intended behavior, represented by the set of one or more predetermined properties, by determining whether one or more of the design verification checks are violated by the hardware design. Finally, results of the verification may be reported.

[0001] This is a divisional of U.S. patent application Ser. No.09/566,684, filed on May 8, 2000, now issued as U.S. Pat. No. 6,651,228,which is hereby incorporated by reference in its entirety.

COPYRIGHT NOTICE

[0002] Contained herein is material that is subject to copyrightprotection. The copyright owner has no objection to the facsimilereproduction of the patent disclosure by any person as it appears in thePatent and Trademark Office patent files or records, but otherwisereserves all rights to the copyright whatsoever.

BACKGROUND

[0003] 1. Field

[0004] Embodiments of the present invention relate generally to thefield of design verification. More particularly, embodiments of thepresent invention relates to a new approach for functional verificationof digital designs.

[0005] 2. Description of the Related Art

[0006] The objective of design verification is to ensure that errors areabsent from a design. Deep sub-micron integrated circuit (IC)manufacturing technology is enabling IC designers to put millions oftransistors on a single IC. Following Moore's law, design complexity isdoubling every 12-18 months, which causes design verification complexityto increase at an exponential rate. In addition, competitive pressuresare putting increased demands on reducing time to market. Thecombination of these forces has caused an ever worsening “verificationcrisis”.

[0007] Today's design flow starts with a specification for the design.The designer then implements the design in a language model, typicallyHardware Description Language (HDL). This model is typically verified todiscover incorrect input/output (I/O) behavior via a stimulus inexpected results out paradigm at the top level of the design.

[0008] By far the most popular method of functional verification today,simulation-based functional verification, is widely used within thedigital design industry as a method for finding defects within designs.A very wide variety of products are available in the market to supportsimulation-based verification methodologies. However, a fundamentalproblem with conventional simulation-based verification approaches isthat they are vector and testbench limited.

[0009] Simulation-based verification is driven by a testbench thatexplicitly generates the vectors to achieve stimulus coverage and alsoimplements the checking mechanism. Testbenches create a fundamentalbottleneck in simulation-based functional verification. In order toverify a design hierarchy level, a testbench must be generated for it.This creates verification overhead for coding and debugging thetestbench. Hence, a significant amount of expensive design andverification engineering resources are needed to produce results in acumbersome and slow process.

[0010] Several methods have been attempted by Electronic DesignAutomation (EDA) companies today in order to address the shortcomings ofsimulation. However, none of these attempts address this fundamentallimitation of the process. For example, simulation vendors have tried tomeet the simulation throughput challenge by increasing the performanceof hardware and software simulators thereby allowing designers toprocess a greater number of vectors in the same amount of simulationtime. While this does increase stimulus coverage, the results areincremental. The technology is not keeping pace with the required growthrate and the verification processes are lagging in achieving therequired stimulus coverage.

[0011] Formal verification is another class of tools that has enteredthe functional verification arena. These tools rely on mathematicalanalysis rather than simulation of the design. The strong selling pointof formal verification is the fact that the results hold true for allpossible input combinations to the design. However, in practice thishigh level of stimulus coverage has come at the cost of both errorcoverage and particularly usability. While some formal techniques areavailable, they are not widely used because they typically require thedesigner to know the details of how the tool works in order to operateit. Formal verification tools generally fall into two classes: (1)equivalence checking, and (2) model checking.

[0012] Equivalence checking is a form of formal verification thatprovides designers with the ability to perform RTL-to-gate andgate-to-gate comparisons of a design to determine if they arefunctionally equivalent. Importantly, however, equivalence checking isnot a method of functional verification. Rather, equivalence checkingmerely provides an alternate solution for comparing a designrepresentation to an original golden reference. It does not verify thefunctionality of the original golden reference for the design.Consequently, the original golden reference must be functionallyverified using other methods.

[0013] Model checking is a functional verification technology thatrequires designers to formulate properties about the design's expectedbehavior. Each property is then checked against an exhaustive set offunctional behaviors in the design. The limitation of this approach isthat the designer is responsible for exactly specifying the set ofproperties to be verified. The property specification languages are newand obscure. Usually the technology runs into capacity problems and thedesigner has to engage with the tools to solve the problems. There aresevere limits on the size of the design and the scope of problems thatcan be analyzed. For example, the designer does not know whichproperties are necessary for complete analysis of the design. Further,specifying a large number of properties does not correlate well withbetter error coverage. Consequently, model checking has proven to bevery difficult to use and has not provided much value in theverification process.

[0014] In view of the foregoing it would be desirable to create averification methodology to create high quality designs without the needfor simulation testbench and to increase the productiveness of designengineers.

SUMMARY

[0015] Methods and apparatus are described for facilitating analysis ofthe intended behavior of a hardware design. According to one embodimentof the present invention, a language-based representation of a hardwaredesign is received. Multiple design verification checks are generatedfor use in connection with model checking by applying a set of one ormore predetermined properties to the language-based representation ofthe hardware design. Then, the hardware design, as implemented accordingto the language-based representation, is verified against intendedbehavior, represented by the set of one or more predeterminedproperties, by determining whether one or more of the designverification checks are violated by the hardware design. Finally,results of the verification may be reported.

[0016] Other features of the present invention will be apparent from theaccompanying drawings and from the detailed description that follows.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0017] Embodiments of the present invention are illustrated by way ofexample, and not by way of limitation, in the figures of theaccompanying drawings and in which like reference numerals refer tosimilar elements and in which:

[0018]FIG. 1 is a block diagram illustrating an exemplary architectureof an Intent-Driven Verification system according to one embodiment ofthe present invention.

[0019]FIG. 2 is a high-level flow diagram illustrating an Intent-DrivenVerification processing according to one embodiment of the presentinvention.

[0020]FIG. 3 is an example of a computer system upon which oneembodiment of the present invention may be implemented.

[0021]FIG. 4A is a high-level block diagram illustrating an exemplarySentry verification entity according to one embodiment.

[0022]FIG. 4B is a schematic diagram illustrating an exemplaryimplementation of a Sentry verification entity according to oneembodiment.

[0023]FIG. 4C illustrates what is meant by concept of flow of logicalsignals according to one embodiment of the present invention.

[0024]FIG. 5 is a flow diagram that illustrates the automaticformulation of design verification checks according to one embodiment ofthe present invention.

[0025]FIG. 6A is a block diagram illustrating a design example.

[0026]FIG. 6B is a block diagram illustrating the design example of FIG.6A with the inclusion of Sentry verification entities.

[0027]FIG. 7 is a state diagram illustrating the operation of the businterface units of FIGS. 6A and 6B.

[0028]FIG. 8 is a simplified state diagram illustrating the operation ofthe round robin arbiter of FIGS. 6A and 6B.

[0029] FIGS. 9A-9E represent an exemplary RTL source code representationof the design example of FIG. 6B.

[0030]FIG. 10 is a block diagram that conceptually illustrates linkingprocessing according to one embodiment of the present invention.

[0031]FIG. 11 is a high-level flow diagram that illustrates linkingprocessing according to one embodiment of the present invention.

[0032]FIG. 12 is a flow diagram that illustrates processing block 1130of FIG. 11 according to one embodiment of the present invention.

[0033] FIGS. 13A-13E illustrate an exemplary text report file for theannotated RTL of FIGS. 9A-9E according to one embodiment of the presentinvention.

DETAILED DESCRIPTION

[0034] Methods and apparatus are described for facilitating analysis ofthe intended behavior of a hardware design. Embodiments of the presentinvention seek to solve or at least alleviate the above-referencedproblems of conventional verification approaches by employing arevolutionary approach for functional verification. According to oneembodiment, an functional verification approach enables verification ofdesign intent prior to simulation and synthesis. Identifying andeliminating design defects early in the design cycle eliminates costlydown-stream design iterations resulting in dramatically shorter designverification cycles.

[0035] Broadly stated, embodiments of the present invention allow errorsin a hardware design to be discovered by checking a representation ofthe hardware design against design intent. In one embodiment, acomprehensive set of design verification checks including behavioralintegrity checks and temporal integrity checks are automaticallygenerated based upon a language representation of a hardware design andinformation regarding the design intent, such as, the intended behavior,or the intended flow of logical signals among a plurality of variablesin the language representation of the hardware design. The design intentmay be communicated to a hardware design verification tool, for example,by way of inline annotations embedded within the hardware designdescription.

[0036] According to one embodiment, a novel “verification entity,”referred to as a Sentry™ verification entity, is provided thatfacilitates modeling and verification of what the designer intended tobuild (SENTRY is a trademark or registered trademark of Real Intent,Inc. of Santa Clara, Calif.). For example, feedback may be provided tothe designer regarding differences between what has actually beencreated by a language representation of a hardware design, such as aRegister Transfer Language (RTL) source code representation, and thedesign intent, e.g., the intended flow of logical signals in a thehardware design.

[0037] Briefly, Sentry verification entities may conceptually be thoughtof as objects, which are embedded in a design during the verificationprocess. Sentry verification entities are not structural entities—theyare not included in the final hardware. Rather, Sentry verificationentities are special purpose objects for support of verification. Sentryverification entities provide a mechanism for expressing design intent.Expressed design intent (i.e., design intent that is explicitly statedby the designer) and implied design intent (i.e., expected behaviorsthat should occur within standard design practices although notexplicitly stated by the designer) are checked against what the designactually accomplishes. As will be described further below, in oneembodiment, Sentry verification entities are embedded within a model ofthe design under test to represent sentinel variables in the designthrough which logical signals in the design pass. For example, a Sentryverification entity may be used to explicitly associate stateinformation with a sentinel variable independent of the value of thesentinel variable. The state information may indicate whether or not thesentinel variable is active or inactive at various points in the controlflow structure of a finite state machine associated with the hardwaredesign representation. Consequently, the integrity of the data flow canbe verified by confirming checks that are expressed as a function of thestates associated with one or more sentinel variables.

[0038] According to another embodiment, a comprehensive set of designverification checks may be formulated by applying predeterminedproperties to an annotated hardware design representation. Theapplication of predetermined properties, such as conflicting assignments(CA), block enable (BE), assignment execution (AX), constant valuememory element (CME), constant value variable (CV), Sentry activatealways off (AAO), loss of valid data (LVD), assertion correctness (AC),and access of invalid data (AID), to signal propagation among all thesentinel variables results in an exhaustive list of checks that confirmwhether or not the predetermined properties hold true for the intendedflow of logical signals. Advantageously, in this manner, a designer getsthe benefits of a comprehensive Intent-Driven Verification™ (IDV™)methodology by simply identifying sentinel variables and providinginformation regarding intended temporal behaviors and/or relationships(INTENT-DRIVEN VERIFICATION and IDV are trademarks or registeredtrademarks of Real Intent, Inc. of Santa Clara, Calif.)

[0039] According to yet another embodiment, an ordered representation ofthe comprehensive set of design verification checks can be created toallow conclusions to be drawn about the hardware design. For example,dependency relationships among the comprehensive set of designverification checks may be determined. A check is dependent upon a setof other checks if it is impossible to violate the first withoutviolating at least one or more checks from the set. After the dependencyrelationships have been determined, this linking information may be usedto facilitate error reporting or to streamline check processing.Notably, reporting of multiple intent violations due to a common designdefect may be avoided thereby containing redundant failures commonlyproduced by prior art simulators. Additionally, if there is no way toviolate the current check being verified without also violating one ormore other previously processed checks, there is no point in reportingthe violation of the current check since this would not communicate anynew information to the user. Finally, assuming it has already beendetermined that a first check cannot be violated, during the processingof a subsequent check, if the current search path violates the firstcheck, then the current search path can be abandoned since there is nosolution along the current search path. In this manner, checks may bemore efficiently processed and the user is not inundated with redundant,cumulative information.

[0040] In the following description, for the purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be apparent, however, toone skilled in the art that the present invention may be practicedwithout some of these specific details. In other instances, well-knownstructures and devices are shown in block diagram form.

[0041] Embodiments of the present invention include various steps, whichwill be described below. The steps may be performed by hardwarecomponents or may be embodied in machine-executable instructions, whichmay be used to cause a general-purpose or special-purpose processorprogrammed with the instructions to perform the steps. Alternatively,the steps may be performed by a combination of hardware and software.

[0042] Embodiments of the present invention may be provided as acomputer program product that may include a machine-readable mediumhaving stored thereon instructions, which may be used to program acomputer (or other electronic devices) to perform a process according tothe present invention. The machine-readable medium may include, but isnot limited to, floppy diskettes, optical disks, CD-ROMs, andmagneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnet or opticalcards, flash memory, or other type of media/machine-readable mediumsuitable for storing electronic instructions. Moreover, the presentinvention may also be downloaded as a computer program product, whereinthe program may be transferred from a remote computer to a requestingcomputer by way of data signals embodied in a carrier wave or otherpropagation medium via a communication link (e.g., a modem or networkconnection).

[0043] For convenience, embodiments of the present invention will bedescribed with reference to Verilog and VHDL. However, the presentinvention is not limited to any particular representation of a hardwaredesign. For example, the language representation of a hardware designmay be in the C programming language, C++, derivatives of C and/or C++,or other high-level languages. In addition, while embodiments of thepresent invention are described with reference to functionalverification of hardware designs, aspects of the present invention areequally applicable to other types of design activities as well, such ashardware synthesis, design optimization, design simulation andperformance analysis. Furthermore, while embodiments of the presentinvention are described with reference to the provision of augmenteddesign information by way of hardware description language (HDL)annotations, it is contemplated that the augmented design informationcould reside in a file separate from the file containing the HDL.Alternatively, semantics capable of capturing augmented designinformation, e.g., intended behavior, may be incorporated within a HDL.

[0044] Terminology

[0045] Brief definitions of terms are given below.

[0046] A “design” generally refers to a description of a collection ofobjects, such as modules, blocks, wires, registers, etc. that representa logic circuit. A design may be expressed in the form of a language.For example, a hardware description language (HDL), such as Verilog orVHDL can be used to describe the behavior of hardware as well as itsimplementation.

[0047] An “annotation” generally refers to text embedded in a languageconstruct, such as a comment statement or remark. Most programminglanguages have a syntax for creating comments thereby allowing toolsdesigned to read and/or process the programming language to read andignore the comments.

[0048] “Simulation” generally refers to the process of evaluating designbehavior for a set of input conditions to draw approximate conclusionsabout the behavior of many different attributes of the design.

[0049] “Formal analysis” generally refers to the process of analyzing adesign for all possible input conditions to derive definite conclusionsabout the behavior of an attribute with respect to the design.

[0050] “Functional verification” generally refers to the process ofapplying stimuli to a design under test with appropriate checkingmechanisms to either detect a defect in the design or to establish thatthe functionality performs as expected. Typically, the three keycomponents of a functional verification process are the appliedstimulus, the checking mechanism, and the user's ability to both run theprocess and debug the results. As will be described later, theeffectiveness of a functional verification process may be measured interms of the following three metrics: (1) error coverage, (2) stimuluscoverage, and (3) usability.

[0051] The term “design intent” generally refers to what the designerintends in terms of the interaction between components of the design andthe designer's expectations regarding acceptable functional behavior.For example, the designer may intend a particular behavior or aparticular flow of logical signals among the variables of an RTL designdescription (the intended flow). Traditionally, design intent hasreferred to input constraints, internal constraints, and/or cause andeffect modeling. In contrast, as used herein the term “design intent”includes “implied design intent” and additional forms of “expresseddesign intent.” Expressed design intent generally refers to designintent explicitly conveyed by a designer by way of intent modelingsemantics in a control file or embedded within annotations of RTL sourcecode (the hardware design representation), for example. Examples ofexpressed design intent regarding the intended flow of logical signalsmay include the intended temporal behaviors (e.g., the ACK signal mustgo high within 4 cycles of the REQ signal) and the intended data flowrelationships (e.g., the data being loaded from the input port is thedata intended for transfer by the driver of the input port). Implieddesign intent generally refers to design intent that is inferred fromthe design description including expected behaviors that should occurwithin standard design practices.

[0052] A “Sentry verification entity” or “verification entity” generallyrefers to an object that may be embedded within a hardware design tofacilitate the modeling of design intent. As described further below,Sentry verification entities provide a mechanism by which stateinformation can be associated with variables in a representation of ahardware design. According to various embodiments of the presentinvention, Sentry verification entities may be used to verify a designby allowing design intent (both expressed and implied) to be checkedagainst what the design actually accomplishes.

[0053] A “property” generally refers to a condition or statement,typically expressed in terms of a relationship among a group of one ormore signals in a hardware design, that must hold for the hardwaredesign to function as intended. According to one embodiment, violationsare reported at the property-level rather than at the more detailedlevel of design verification checks.

[0054] The term “design verification check” or simply “check” generallyrefers to a mechanism for verifying a property. Properties may becomposed of one or more checks, which are the atomic units that areverified. That is, properties may be broken down into one or morechecks. Since properties and checks are sometimes equivalent (i.e., whena property comprises a single design verification check), these termsmay at times be used interchangeably. Examples of checks include, butare not limited to: monitors, Boolean conditions, sensitized pathconditions, and the like. According to one embodiment, a comprehensiveset of checks may be automatically formulated based upon arepresentation of the hardware design and information regarding theintended flow of logical signals among a plurality of variables in therepresentation.

[0055] Check A is said to be “dependent” upon checks B, C, and D if itis impossible to violate check A without violating at least one ofchecks B, C, and D. If check A is dependent upon check B, C and D, thena “dependency relationship” exists between check A and checks B, C, andD.

[0056] Characteristics of Effective Functional Verification

[0057] As mentioned earlier, the effectiveness of a functionalverification process may be measured in terms of error coverage,stimulus coverage, and usability. Error coverage refers to the abilityof the verification methodology to identify a broad range of potentialdesign defects. A verification process should be effective inidentifying all potential failures in a hardware design. This isachieved by creating a checking mechanism. In traditional practice, thechecking mechanism is created by comparing the hardware designrepresentation, e.g., RTL source code, to an independently createddesign model. This independent model is used to predict the response ofthe design for comparison. Given that the purpose of the verificationprocess is to assure design quality, it is important to build a verycomprehensive checking mechanism.

[0058] Stimulus coverage refers to the ability of the verificationmethodology's ability to achieve broad coverage of the input domain.Preferably, the verification process should examine all possiblecombinations of input sequences for the design under test. High stimuluscoverage is critical to verification, particularly with designscontaining large numbers of states. Yet, all existing technologies fallshort here. The ideal verification process should achieve exhaustivestimulus coverage for any design.

[0059] Usability refers to the overall ease and effectiveness of userinteraction with the verification tool. The verification process shouldbe simple and effective to use. To accomplish this, setup costs forrunning the process should be minimized, and the reported informationshould be well organized to allow easy debugging. The process should fitwell into existing design methodologies and should require a minimumamount of training in order to be used effectively. Usability should begiven high priority when developing any functional verification systemand should not be an afterthought that is secondary to the underlyingtechnology.

[0060] Intent-Driven Verification Overview

[0061] Intent-Driven Verification (IDV) is a revolutionary approach forfunctional verification of hardware designs. IDV ranks high on all threeof the above-described metrics and successfully integrates thetechnologies required for an effective functional verification systemtogether into a complete package. Briefly, IDV identifies the “intentgap” between what a designer intends to build (design intent) and whathas actually been created within the language representation of thehardware design (design implementation), such as RTL source code. Byaugmenting the RTL source code or associated control file withinformation indicative of the designer's intent, a comprehensive set ofchecks can be automatically formulated and verified. As mentioned above,the RTL may also be expanded to include semantics capable of conveyinginformation indicative of the designer's intent or desired functionalbehavior. This provides a novel and effective way to identify designproblems early in the development process. Additionally, IDV isscalable, provides fast isolation of the source of defects, andsignificantly reduces the overall verification effort, thus enabling ICdesign projects to dramatically reduce their time to market.

[0062] An Exemplary Intent-Driven Verification System

[0063]FIG. 1 is a block diagram illustrating an exemplary architectureof an Intent-Driven Verification (IDV) system according to oneembodiment of the present invention. According to the embodimentdepicted, the IDV system 100 includes an annotated hardware designrepresentation reader 120. The annotated hardware design representationreader 120 may be a conventional RTL reader with the additional abilityto recognize and process augmented design information. Alternatively,the annotated hardware design representation reader 120 may be aconventional C or C++ parser capable of processing the augmented designinformation. In one embodiment, the augmented design informationcomprises annotations embedded within the hardware design representation105, such as an annotated RTL source code file 105 containing specialverification semantics (directives). Exemplary directives and theirsyntax are described further below. In alternative embodiments, theaugmented design information may be included in a control fileassociated with the hardware design representation 105, such as controlfile 115.

[0064] The IDV system 100 also includes a control file reader 130. Thecontrol file reader 130 may be a conventional control file reader.Alternatively, in the case that the augmented design information (e.g.,information regarding design intent, such as the intended flow oflogical signal among variables in the hardware design representation) isto be provided by way of control file 115, then the control file reader130 additionally includes parsing functionality enabling the controlfile reader 130 to recognize and process the augmented designinformation.

[0065] According to the architecture depicted, the IDV system 100 alsoincludes a model builder 145, a design intent analyzer 140, a propertymanager 165, an analysis engine 180, and a report manager 170. The modelbuilder 145 receives output of the hardware design representation reader120, the control file reader 130, and a cell library (not shown) andbuilds an internal representation of the hardware design, a model.Additionally, based upon the designer's expressed design intent and/orimplied intent, the model builder embeds special verification entitiesinto the model for the purpose of identifying the intent gap betweenwhat the designer intended to build (design intent) and what hasactually been created within the source code (design implementation).These special embedded objects are referred to as Sentry verificationentities. Details regarding the use, functionality, and implementationof Sentry verification entities are presented below.

[0066] The design intent analyzer 140 automatically produces acomprehensive set of design verification checks, such as behavioralintegrity checks and temporal integrity checks, based upon apredetermined set of properties and the Sentry verification entities.For example, for each Sentry verification entity in the model, thedesign intent analyzer 140 may automatically create checks to verifythat there is no access of invalid data by the Sentry verificationentity and that no active data from the Sentry verification entity islost. Other properties and verification of these properties, in terms ofchecks and Sentry verification entities, are discussed below.Consequently, by merely associating the Sentry attribute with a variablein an RTL representation of the hardware design and providing minimaladditional information regarding the desired/expected interactionbetween components of the design and regarding expectations foracceptable functional behavior, the design intent analyzer 140 enablesverification while the design is being developed and facilitatesdetection of design defects at the RTL-level. Advantageously, in thismanner, the designer is not required to manually code individualmonitors for each property he/she would like to verify. Rather,verification cycle time and resource requirements are reduces byallowing the designer to simply associate the Sentry attribute withcertain important variables, sentinel variables (e.g., by “declaring”the sentinel variables as Sentry verification entities), provide minimaladditional information regarding the desired/expected interactionbetween components of the design (such as an indication regarding theexpected state of the sentinel variables at various points in thecontrol flow structure of a finite state machine associated with thehardware design representation), and the generation of a complete set ofchecks involving the sentinel variables is automatically performed.Importantly, the use of Sentry verification entities to enable automaticformulation of a comprehensive set of design verification checks notonly dramatically reduces verification effort and time but alsosignificantly increases design robustness.

[0067] The property manager 165 maintains information regardingrelationships among the checks generated by the design intent analyzerand additionally maintains information regarding relationships amongproperties and whether the properties are satisfied, violated, orwhether the results are indeterminate or conditional upon one or moreother properties. According to one embodiment, the property manger 165and analysis engine 180 cooperate to determine dependency relationshipsamong the comprehensive set of design verification checks. As describedfurther below, the dependency relationships (or “linking” information)may be used to facilitate error reporting or used to streamline checkprocessing.

[0068] The analysis engine 180 verifies the model produced by the modelbuilder by testing for violations of the properties. Preferably, theanalysis engine 180 employs an analysis-based technique, such as anintegration of simulation and formal analysis methodologies, so as tomaximize stimulus coverage for the design under test. However, inalternative embodiments, simulation, functional verification, or otherwell-known verification methodologies may be employed individually.

[0069] The report manager 170 provides feedback to the designer, in theform of a report file 175, for example, regarding potential designdefects. It should be noted that a single error in the hardware designmight lead to a violation of 25 to 30 or more different designverifications checks. There is no point in reporting every violation ifthe user has already been notified that an error exists. Therefore,according to one embodiment, an intent violation hierarchy may bemaintained when reporting design defects. In this manner, redundancy ofreported information is contained. Multiple intent violations due to acommon defect are not reported. This minimizes the amount of data to beanalyzed to detect defects.

[0070] High-Level Intent-Driven Verification Processing

[0071]FIG. 2 is a high-level flow diagram illustrating Intent-DrivenVerification processing according to one embodiment of the presentinvention. The Intent-Driven Verification process generally breaks downinto three fundamental technologies, intent capture, intent gapdetection, and intent violation reporting. A method for capturing thedesigner's intent for the design (intent capture) is represented byprocessing blocks 210-230, detection of areas within the design sourcecode that differ from the original design intent (intent gap detection)comprises processing block 240, and identification and reporting of thespace between the designer's intent and the design's implementation(intent violation reporting) is represented by processing block 250.Briefly, after a complete view of the overall design intent is captured,e.g., after the two forms of intent are integrated together by thedesign intent analyzer 140, the analysis engine 180 may beginidentifying individual intent violations. When the analysis is complete,the report manager 170 provides feedback to the user in a well-organizedmanner. In one embodiment, the processing blocks described below may beperformed under the control of a programmed processor, such as processor302. However, in alternative embodiments, the processing blocks may befully or partially implemented by any programmable or hardcoded logic,such as Field Programmable Gate Arrays (FPGAs), TTL logic, orApplication Specific Integrated Circuits (ASICs), for example.

[0072] Intent-Driven Verification processing begins at processing block210 where a language representation of a hardware design under test isreceived. The language representation may be RTL source code, such asVerilog or VHDL. Preferably, to take advantage of the control flowstructure of the language representation, augmented design informationis provided by inline annotations to the language representation of thehardware design, e.g., annotated RTL 105. However, in alternativeembodiments, design intent may be provided in the control file 115.

[0073] In this example, at processing blocks 220 and 230, the designintent is captured in two basic forms: expressed and implied. Expresseddesign intent is design intent that is explicitly stated by thedesigner. The implementation of IDV described herein may use an elegantRTL-based method to express this intent in an annotated RTL source codefile, such as annotated hardware description representation 105, and/orthe control file 115. Regardless of their source, the expressed designintent is determined based upon the annotations. Importantly, the formof intent modeling provided herein is very intuitive and does notrequire the users to learn a new language. Additionally, this intentmodeling captures the intent in a concise manner and thereby minimizessetup effort. Typically, the expressed intent defines the interactionbetween components of the design and/or the designer's expectationsregarding acceptable functional behavior. Implied design intent may beinferred directly from the design description. Advantageously, impliedintent capture infers numerous and complex design behaviorsautomatically without requiring a designer to explicitly state them.Typically, this consists of expected behaviors that should occur withinstandard design practices.

[0074] At processing block 240, the intent gap is identified based uponthe design intent and the design implementation. In the exampledepicted, the two forms of design intent are integrated and used asinput to processing block 240. In alternative embodiments, the intentgap may be determined for only a single form of design intent or one ormore other combinations of subsets of expressed and implied designintent. At any rate, preferably, the intent gap is statically identifiedusing functional verification techniques. The intent gap is the distancebetween a design's intent and the actual implementation. According toone embodiment, IDV detects the intent gap in terms of individual intentviolations. Intent violations are the result of defects within thedesign implementation. Importantly, because the intended behavior of thedesign is well understood, intent violations isolate design defects withhigh localization to their source.

[0075] At processing block 250, feedback is provided to the user. Forexample, one or more report files 175 may be created that provideinformation regarding the individual intent violations identified inprocessing block 240. Preferably, the redundancy of information iscontained and the intent violation data is organized into a format thatprovides useful and highly accurate debugging information to a designer.Additionally, sequential debugging information may be provided alongwith detailed explanations of any identified intent violations. Anexemplary report file format is illustrated in FIGS. 13A-13E.

[0076] An Exemplary Computer Architecture

[0077] Having briefly described an exemplary verification system inwhich various features of the present invention may be employed andhigh-level Intent-Driven Verification processing, an exemplary machinein the form of a computer system 300 representing an exemplaryworkstation, host, or server in which features of the present inventionmay be implemented will now be described with reference to FIG. 3.Computer system 300 comprises a bus or other communication means 301 forcommunicating information, and a processing means such as processor 302coupled with bus 301 for processing information. Computer system 300further comprises a random access memory (RAM) or other dynamic storagedevice 304 (referred to as main memory), coupled to bus 301 for storinginformation and instructions to be executed by processor 302. Mainmemory 304 also may be used for storing temporary variables or otherintermediate information during execution of instructions by processor302. Computer system 300 also comprises a read only memory (ROM) and/orother static storage device 306 coupled to bus 301 for storing staticinformation and instructions for processor 302.

[0078] A data storage device 307 such as a magnetic disk or optical discand its corresponding drive may also be coupled to computer system 300for storing information and instructions. Computer system 300 can alsobe coupled via bus 301 to a display device 321, such as a cathode raytube (CRT) or Liquid Crystal Display (LCD), for displaying informationto an end user. For example, graphical and/or textualdepictions/indications of design errors, and other data types andinformation may be presented to the end user on the display device 321.Typically, an alphanumeric input device 322, including alphanumeric andother keys, may be coupled to bus 301 for communicating informationand/or command selections to processor 302. Another type of user inputdevice is cursor control 323, such as a mouse, a trackball, or cursordirection keys for communicating direction information and commandselections to processor 302 and for controlling cursor movement ondisplay 321.

[0079] A communication device 325 is also coupled to bus 301. Dependingupon the particular design environment implementation, the communicationdevice 325 may include a modem, a network interface card, or otherwell-known interface devices, such as those used for coupling toEthernet, token ring, or other types of physical attachment for purposesof providing a communication link to support a local or wide areanetwork, for example. In any event, in this manner, the computer system300 may be coupled to a number of clients and/or servers via aconventional network infrastructure, such as a company's Intranet and/orthe Internet, for example.

[0080] Modeling Intended Flow of Logical Signals in a Hardware Design

[0081] Currently available verification methodologies lack suitablemechanisms to allow designers to adequately express their design intent.Rather, existing functional verification methodologies, such as modelchecking, generally require a designer to formulate properties about thedesign's expected behavior. Consequently, the designer is responsiblefor exactly specifying the set of properties to be verified. One problemwith this approach, however, is that the designer may not know or evenbe capable of knowing which properties are necessary for a completeanalysis of the design. Additionally, the property specificationlanguages are new and obscure and typically require the designer to knowthe details of how the verification tool works in order to operate it.

[0082] Briefly, the intent modeling techniques described herein seek toraise the level of abstraction of the verification process to increasethe productiveness of existing design environments/design verificationtools. In particular, there is no need for the designer to have anyknowledge regarding the internal details of tools employing these intentmodeling techniques. Rather, the designer is free to focus oncharacteristics of the design under test. For example, according to oneembodiment, incorporation of Sentry verification entities into ahardware design representation only requires simply annotationsindicative of the expected state of variables at various points in thecontrol flow structure of a finite state machine associated with thehardware design representation.

[0083] Referring now to FIG. 4A, a high-level block diagram illustratingan exemplary Sentry verification entity 400 will now be described. Atthis level, the Sentry verification entity 400 may be conceptuallythought of as an object that enables explicit association of stateinformation with variables of a language description of a hardwaredesign. This association may be accomplished by “declaring” a variable,e.g., an interconnect in the hardware design representation through withlogical signals pass, as a Sentry verification entity resulting in thecreation of a sentinel variable. Data in 420 represents a flow of datasignals into to the sentinel variable (e.g., an assignment of a datavalue to the sentinel variable); and data out 440 represents a flow ofdata signals out of the sentinel variable (e.g., an assignment of thecurrent data value of the sentinel variable to another variable in therepresentation of the hardware design). As described further below, oneor more control signals 410 may be employed to represent the intendedflow of logical signals among sentinel variables by associating expectedstates with the sentinel variables at different points of the designscontrol flow. Additionally, design verification checks, expressed as afunction of the expected states of the sentinel variables, may beautomatically formulated thereby allowing the integrity of the data flowto be verified by confirming whether or not any positive checks (e.g.,checks that indicate a design defect when there is a solution) areviolated or whether or not a counterexample may be found for anynegative checks (e.g., checks that indicate a design defect when thereis not a solution).

[0084]FIG. 4B is a schematic diagram illustrating an exemplaryimplementation of a Sentry verification entity 400 according to oneembodiment. In the embodiment depicted, the Sentry verification entity400 includes a state latch 445 to store the current state 435 of avariable. The Sentry verification entity 400 also includes statemaintenance logic 455 for maintaining the state 435 or updating thestate 435 based upon a deactivate control signal 411 and an activatesignal 412. In this example, the state maintenance logic 455 comprisesan AND gate 415 and an OR gate 425. The AND gate 415 receives thecurrent state 435 of the corresponding variable from the state latch 445and an inverted version of the deactivate control signal 411. The ORgate 425 receives the output of the AND gate 415 and the activatecontrol signal 412. Consequently, the state maintenance logic 455outputs the same state input from the state latch 445 when both theactivate control signal 412 and the deactivate control signal 411 arelogic 0 thereby holding the variable's current state. The state 435transitions to active, e.g., logic 1, if the activate control signal islogic 1; and the state 435 transitions to inactive, e.g., logic 0, ifthe deactivate control signal is logic 1. In this example, the inputcombination of logic 1 on both the activate control signal 412 and thedeactivate control signal 411 is invalid. Importantly, while forsimplicity the present example is illustrated with two states, activeand inactive, the concept of associating state information with avariable in a hardware design representation by Sentry verificationentities is extensible to more than two states. Also, it is appreciatedthat the implementation of the Sentry verification entity 400 may havemany equivalent logical representations than that depicted in FIG. 4B.The implementation of FIG. 4B, therefore, is to be considered merelyrepresentative of one or the many various possible logically equivalentimplementations.

[0085]FIG. 4C illustrates what is meant by concept of intended flow oflogical signals according to one embodiment of the present invention. Inone embodiment, if a path (not necessarily a “sensitized path”) existsbetween two sentinel variables, then there is a flow of logical signalsfrom one to the other. In this example, since the outputs of sentinelvariables 401, 402, and 403 are all electrically coupled to the input ofsentinel variable 405 in the resultant hardware component, designverification checks associated with sentinel variable 405 will be afunction of at least the state of sentinel variables 401, 402, and 403.Notably, in this example, there is not always a “sensitized path”between each of the sentinel variables 401, 402, and 403 and sentinelvariable 405 as the output of any given sentinel variable 401, 402, and403 does not always have an effect on the value of sentinel variable405. Consequently, it may be said that a design structure implements theintended flow of logical signals between key elements (e.g., sentinelvariables) in the design where the intended flow of logical signalsconsists of: (1) The logical signal at a key destination design element,at a given time, resulted from the logical signals at a set of keysource design elements, at the same or earlier time, and would bedifferent or will not change if a key source signal was different or didnot change respectively; (2) The logical signal at a key destinationdesign element, at a given time, independent of the logical signals at aset of key source design elements, at the same or earlier time, and willnot change if a key source signal was different, (3) The logical signalat a key source design element, at a given time, should not govern thelogical signal at a key destination design element. This intended flowof logical signals can be inferred from the states associated with thekey variables and the rules for correct design behavior.

[0086] Exemplary Annotations

[0087] Various statements that may be used to make up annotations willnow be described. According to one embodiment, annotations can beentered in one of two ways: (1) A Single Line // vx statement; (2)Multiple Lines /* vx code ON  statement;  statement; */

[0088] According to one embodiment, any synthesizeable Verilog can alsobe entered within the context of an annotation to create additionalvalidation checks. Importantly, by placing these annotations within theRTL code itself, the designer performs three tasks in one:

[0089] 1. Documents the source code through the assertions

[0090] 2. Identifies assumptions made during block development

[0091] 3. Prepares the RTL for validation

[0092] Several built-in constructs may be used in annotations orsemantics of the RTL to simplify assertion coding. The examples listedin Table 1 cover common behaviors that many signal groups exhibit. Inthese examples, the syntax for an annotation comprises a commentdelimiter (e.g., “//” or a “/*” “*/” pair), a directive marker (e.g.,“vx”), a directive (e.g., “onehot”), and optional directive parameters(e.g., variables i, j, and k). TABLE 1 Built-in Assertions AnnotationMeaning // vx onehot (i,j,k); Exactly one of i, j, or k must be high //vx onecold (i,j,k); Exactly one of i, j, or k must be low // vx onetrue(i,j,k); At most one of i, j, or k can be high // vx onefalse (i,j,k);At most one of i, j, or k can be low

[0093] Such assertions allow the designer to explicitly specify designconstraints for annotated signals. According to one embodiment,techniques are also provided for implicit design constraints based uponthe control flow in the circuit. These implicit constraints are thoughtto be key to both block and interface validation.

[0094] In any design, signals are used to coordinate informationexchange between different sections of the circuit. Such signals may bethe contents of a data bus, or the handshaking signals between twointeracting state machines. These key signals are referred to herein assentinel variables of the design. The purpose of other logic in thecircuit is to ensure proper interaction between these signals. A designfailure is nothing but the incorrect exchange of data among sentinelvariables.

[0095] According to one embodiment, sentinel variables are identified inannotations by the “sentry” directive. Sentry verification entities maybe used to identify a sentinel signal and to model its behavior. In theexamples described herein, Sentry verification entities have two states,active and inactive, that are controlled by “activate” and “deactivate”directives presented in vx annotations. The various Sentry verificationentity controls, e.g., in the form of annotations, are placed in thecontrol flow of the design so that the state of the Sentry verificationentity is dependent on the state of the design. The Sentry verificationentity should be activated when its corresponding sentinel variablecarries valid information that is utilized somewhere in the design, anddeactivated when the data is invalid or not used. Importantly, accordingto one embodiment, IDV automatically validates multiple forms of dataexchange between sentinel variables to ensure that the exchange isalways valid. This checking mechanism works both in block-level andfull-chip validation.

[0096] According to one embodiment, the designer is responsible foridentifying signals that should be modeled as Sentry verificationentities. Common sentinel variables in a design are: handshakingsignals, data buses, state variables, and output ports. After sentinelvariables have been identified, the designer may add appropriateannotations to the design representation.

[0097] Any signal (wire, register, or I/O) may be declared as a Sentryverification entity. A Sentry verification entity may also be declaredon a sub-range of a vector. Each Sentry verification entity declarationshould also identify a clock signal that controls when the correspondingsentinel variable may change its value. The following are examples ofsentry annotations: reg a; // vx sentry a: clk; wire b; // vx sentry b:clk; reg [0:15] c; // vx sentry [1:2] c: clk;

[0098] According to one embodiment, Sentry verification entitiesalternate between active and inactive states based upon the control flowin the design. For instance, a data bus controlled by a state machinemay be declared as a Sentry verification entity. When the state machineis in the idle state, the data bus Sentry verification entity isdeactivated. Once the state machine enters a transmitting state, thedata bus Sentry verification entity is activated. Any other Sentryverification entities in the design that try to access the data buswhile it is deactivated will be flagged as an error, such as a “bad dataaccess” error. Similarly, a design defect is indicated if no otherSentry verification entities in the design are accessing the data buswhile it is active. For example, a “data loss” may be reported.

[0099] According to one embodiment, Sentry verification entities may beactivated and deactivated using the annotations in Table 2. TABLE 2Exemplary Sentry verification entity controls Annotation Meaning // vxactivate(a); Activate Sentry a: // vx deactivate(a); Deactivate Sentrya:

[0100] Sentry annotations may be placed within the control flow of thedesign so that the state of the Sentry verification entity is dependenton the control state. Sentry annotations can also be coded using the“//vx code ON” annotation thereby allowing the designer to code theSentry verification entity states within their own annotation blockseparate from the source code for the hardware design representation.

[0101] Formulation of Design Verification Checks

[0102]FIG. 5 is a flow diagram that illustrates the automaticformulation of design verification checks according to one embodiment ofthe present invention. As described above, properties may be verified bybreaking them down into one or more checks and performing verificationprocessing at the check-level. Briefly, according to this example, a setof predetermined properties are applied to each sentinel variable in thedesign representation. More specifically, the predetermined propertiesare applied to signal propagation among the sentinel variables toproduce an exhaustive list of checks that confirm whether or not thepredetermined properties are violated for the intended flow of logicalsignals.

[0103] According to the embodiment depicted, design verification checkformulation begins at processing block 510 where a model of the hardwaredesign under test is received. Preferably, the model includes embeddedobjects, such as Sentry verification entities, associated with eachsentinel variable to facilitate check generation. At processing block520, the model is traversed to locate the next sentinel variable. Uponlocating the next sentinel variable, at processing block 530, designverification checks for the sentinel variable are automaticallyformulated based upon the predetermined properties. For example, eachproperty may be expressed as one or more checks. Further, many of thechecks may be expressed at least partially as a function of the statesof one or more sentinel variables as described further below.

[0104] At processing block 540, a determination is made whether or notthe model traversal is complete. If so, processing proceeds toprocessing block 550. Otherwise, processing returns to processing block520. At processing block 550, the design verification checks generatedin processing block 530 are added to the property manager for subsequentlinking and analysis, for example, which are described further below.

[0105] Exemplary Properties/Design Verification Checks

[0106] Empirical analysis performed by the assignee has shown thatverification of a relatively small set of properties at key points of ahardware design representation (e.g., handshaking signals, data buses,state variables, and output ports) can guarantee the absence of errorsin the hardware design with a high level of confidence.

[0107] An exemplary set of properties will now be described.Importantly, however, the present invention should not be construed asbeing limited to this particular set of properties or the use ofsentries. In various circumstances, a subset of the properties describedbelow may be sufficient to achieve the desired level of confidence.Additionally, the set of properties described herein is not intended tobe an exhaustive list. It is contemplated that Sentry verificationentities and the verification techniques described herein would beequally useful in the context of a larger set of properties or even acompletely different set of properties.

[0108] In one embodiment, the predefined set of properties applied tosignal propagation among the sentinel variables of the hardware designrepresentation include: access of invalid data (AID), loss of valid data(LVD), assertion correctness (AC), conflicting assignments (CA), blockenable (BE), assignment execution (AX), constant value memory element(CME), constant value variable (CV), Sentry activate always off (AAO).

[0109] AID (Access of Invalid Data) is an undesirable condition. ASentry verification entity that is in the valid state should not receivedata that flowed through a Sentry verification entity that was in theinvalid state. Therefore, a solution to one or more checks representinga violation of this property is indicative of a design defect. Accordingto an embodiment of the present invention, an approach for finding AIDis to search for an input sequence for the sentinel variable underverification, starting from the reset state, that will: (1) set thecorresponding destination Sentry verification entity in the valid state,(2) create a sequentially sensitized path from a source Sentryverification entity to the Sentry verification entity underverification, and (3) set the source Sentry verification entity in theinvalid state at the time when the sensitive data was flowing throughthe destination Sentry verification entity.

[0110] LVD (Loss of Valid Data) is another undesirable condition. Anydata flowing through a Sentry verification entity that is in the validstate must be received by some Sentry verification entity that is in thevalid state. Therefore, a solution to one or more checks representing aviolation of this property is indicative of a design defect. Accordingto an embodiment of the present invention, an approach for finding LVDis to search for an input sequence for the sentinel variable underverification, starting from the reset state, that will: (1) set thecorresponding source Sentry verification entity in the valid state, and(2a) block the sensitized paths between the source Sentry verificationentity and all possible destination Sentry verification entities, or (2b) set the destination Sentry verification entities with sensitizedpaths from the source Sentry verification entity, in the invalid state.

[0111] AC (Assertion Correctness) is a desired condition. An assertionrepresents a condition the designer explicitly indicated should occur ata particular point in the design. Consequently, a counterexample forcompliance with the assertion is indicative of a design defect.According to an embodiment of the present invention, an approach fordetermining an AC violation is to search for an input sequence for thesentinel variable under verification, starting from the reset state,that will be a counterexample for the assertion.

[0112] The remaining properties (i.e., conflicting assignments, blockenable, assignment execution, constant value memory element, constantvalue variable, and Sentry activate always off) may be verified in asimilar manner. However, for sake of brevity, checking algorithms forthese properties will not be described. Rather, only brief descriptionswill be provided. CA (Conflicting Assignments) is an undesirablecondition where a wire in the design can be driven by multipleconflicting drivers. BE (Block Enable) checks if the condition enablingthe execution of a certain block of code in the HDL will never beenabled. AX (Assignment Execution) checks to see if each logical valuecan be assigned to a variable through each assignment. CME (ConstantValue Memory Element) checks to see if a memory element in the designwill always hold a constant value. CV (Constant Value Variable) checksto see if a variable in the design will always hold a constant value.AAO (Sentry Activate Always Off) is an undesirable condition indicativeof an error in the specification of the design intent where a sentryverification entity is never set in active state.

[0113] An Exemplary Design Example

[0114] In the design example illustrated by FIGS. 6-9, it is assumedthat there is a need for three independent units, such asmicroprocessors, client A 605, client B 610, and client C 615, that arerequired to share access to the same memory 640, such as a synchronousRAM. In this design example, it is assumed that the memory 640 requiresa single read/write signal. The following data/control signals aretherefore needed from each unit: (1) Address-10 bits, (2) Write data-8bits, (3) Read data-8 bits, and (4) Read/write-1 bit. As a result, anarbiter, such as round robin arbiter 636, has been designed that acceptsdata from each unit 605, 610, and 615 and arbitrates to determine whichone is granted access to the memory 640 at any one time. Each unit 605,610, and 615 will initiate a memory request signal when it wants accessto the memory 640 and will deactivate it when finished. If more than oneunit 605, 610, and 615 requests the bus 641 at the same time, accessshould be grated on a “round-robin” basis so that no one unit 605, 610,or 615 is locked out while another has continuous access. Continuousaccess is granted to any one unit 605, 610, or 615 for a period of time,up to a number of clock cycles separately programmable from client A'sdata bus 606. When a programmable “watch dog” time has not been set, an8 clock cycle delay should default. For speed purposes, the use ofTri-state buffers, rather than multiplexers is desirable.

[0115]FIG. 6B is a block diagram illustrating the design example of FIG.6A with the inclusion of Sentry verification entities at appropriatepoints of the circuit corresponding to the RTL representation of FIGS.9A-9E. Thus, FIG. 6B conceptually illustrates the internal modelrepresentation after the model builder 145 embeds Sentry verificationentities 645, 650, 655, 660, 665, and 670; and as seen by the designintent analyzer 140 and the analysis engine 180.

[0116] In this example, the Sentry verification entities 645, 650, 655,660, 665, and 670 have been chosen to (1) verify the operation of thesignals between clients 605, 610, and 615 and bus interface units (BIUs)620, 625, and 630, respectively; and (2) verify the operation of thesignals between the BIUs 620, 625, 630 and the round robin arbiter 635.The data signals (i.e., dataA, dataB, and dataC) flowing from clients605, 610, and 615 to bus interface units (BIUs) 620, 625, and 630,respectively, are declared as sentinel variables at line 20 of FIG. 9A.The data signals (i.e., dataOut) flowing from BIUs 620, 625, and 630 toclients 605, 610, and 615, respectively, are declared as sentinelvariables at line 50 of FIG. 9B. The data signals (i.e., dataA, dataB,and dataC) received by the round robin arbiter 635 are declared assentinel variables at line 115 of FIG. 9C.

[0117] The states associated with the Sentry verification entities 645,650, 655, 660, 665, and 670 at different points of the control flow arecontrolled by way of annotations at line 21 of FIG. 9A, at lines 73, 81,and 91 of FIG. 9B, at line 131 of FIG. 9C, and at lines 156, 169, and180 of FIG. 9D. In this example, therefore, the designer has expressedhis/her intent that (1) the Sentry verification entities associated withdataA, dataB, and dataC remain active constantly in module main; (2) onreset, the Sentry verification entity associated with dataOut isdeactive; (3) the Sentry verification entity associated with dataOut isdeactive when the corresponding BIU is in the “NO_REQ” state and activewhen the corresponding BIU is in the “GRANTED” state; (4) the Sentryverification entities associated with dataA, dataB, and dataC aredeactive during state transition of the round robin arbiter 635; and (5)the Sentry verification entities associated with dataA, dataB, and dataCare activated when the round robin arbiter is in “stateA”, “stateB”, and“stateC”, respectively, thereby allowing only one of dataA, dataB, anddataC to be active at any given time.

[0118] An exemplary text report file illustrating the verificationresults for the annotated RTL of FIGS. 9A-9E will be described belowwith reference to FIGS. 13A-13E.

[0119] Linking

[0120] As mentioned above, the property manager 165 may trackinformation regarding relationships among the various designverification checks generated by the design intent analyzer. In theembodiments described herein, the linking process is performedconcurrently with verification of the checks. In alternativeembodiments, however, linking and verification processing may beperformed separately. In any event, the dependency relationships (or“linking” information) may be used to facilitate error reporting or usedto streamline check verification processing.

[0121]FIG. 10 is a block diagram that conceptually illustrates linkingprocessing according to one embodiment of the present invention.According to this example, link processing involves both the propertymanager 165 and the analysis engine 180. The property manager 165provides the next check 1005 to be processed to the analysis engine 180;and the analysis engine 180 returns link information 1010, such aswhether or not the currently processed check is dependent upon anothercheck and if so, which check. The analysis engine 180 includes a linkingprocess 1020 and a local model 1025. The local model 1025 is initializedwith a copy of the model 1015 generated by the model builder. However,during link processing, the local model is modified to disable variouschecks.

[0122]FIG. 11 is a high-level flow diagram that illustrates linkingprocessing according to one embodiment of the present invention. Atprocessing block 1110, the next design verification check is received bythe analysis engine 180 from the property manager 165. In order to avoidcircular dependency relationships, those design verification checks thatare already known to be dependent upon the received design verificationcheck are disabled in the local model 1025 at processing block 1120. Thereceived design verification check is evaluated at processing block 1130and appropriate linking is also performed. Then, at processing block1140, all of the design verification checks are enabled in anticipationof further check processing. Finally, at decision block 1150, adetermination is made whether or not there are more checks to beprocessed. If so, control flow returns to processing block 1110.Otherwise, link processing is complete.

[0123]FIG. 12 is a flow diagram that illustrates processing block 1130of FIG. 11 according to one embodiment of the present invention.Processing of the received design verification check begins atprocessing block 1231 where the previous partial solution is expanded tocreate a current partial solution. Next, at processing block 1232, thecurrent partial solution is evaluated; and a determination is made atprocessing block 1233 whether or not the current partial solutionviolates an independent check. If it is determined that the currentpartial solution violates an independent check, then processing proceedsto processing block 1235. Otherwise, processing branches to decisionblock 1234.

[0124] At decision block 1234 the current partial solution is tested todetermine whether or not it is complete. If the current partial solutionis complete, then the currently processed check is marked as anindependent check and processing continues with processing block 1238.Otherwise, if the current partial solution is not complete, thenprocessing returns to processing block 1231.

[0125] Assuming the current partial solution has been found to violatean independent check, then at processing block 1235, the current checkis temporarily locally marked as being dependent upon the independentcheck. At processing block, a determination is made whether or not thecurrent partial solution can be rectified to remove the violation of theindependent check. If the current partial solution can be so rectified,then processing proceeds to processing block 1237. Otherwise, processingcontinues with processing block 1238. At processing block 1237, thecurrent solution is rectified to remove the violation and control flowreturns to processing block 1231.

[0126] Finally, at processing block 1238, the local dependencyinformation is used to update the master dependency information in theproperty database 160. In this manner, an intent violation hierarchy maybe built for use during reporting of design defects.

[0127] Intent Violation Reporting

[0128] FIGS. 13A-13E illustrate an exemplary text report file for theannotated RTL of FIGS. 9A-9E according to one embodiment of the presentinvention. In this example, a summary of the functional checks is listedat lines 5 through 17. The summary indicates a total of five failedchecks, three inconclusive checks, twelve interface checks, and 144passed checks (some of which may be conditional). A summary of thefailed checks is listed at lines 27 through 38. One block enableviolation is reported at line 31, one assignment execution violation isreported at line 32, and three occurrences of loss of valid data arereported at line 38 of FIG. 13A. Exemplary detailed debugginginformation regarding the property violations is shown in FIG. 13B.

[0129] In the foregoing specification, the invention has been describedwith reference to specific embodiments thereof. It will, however, beevident that various modifications and changes may be made theretowithout departing from the broader spirit and scope of the invention.The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense.

What is claimed is:
 1. A method comprising: receiving a language-basedrepresentation of a hardware design; automatically generating aplurality of design verification checks for use in connection with modelchecking, the plurality of design verification checks based uponapplication of a set of one or more predetermined properties to thelanguage-based representation of the hardware design; verifying thehardware design, as implemented according to the language-basedrepresentation, against intended behavior, represented by the set of oneor more predetermined properties, by determining whether one or more ofthe plurality of design verification checks are violated by the hardwaredesign; and reporting results of said verifying.
 2. The method of claim1, wherein the language-based representation of the hardware designcomprises Register Transfer Language (RTL) source code.
 3. The method ofclaim 2, wherein the one or more predetermined properties include ablock enable property that relates to whether conditions enablingexecution of a particular block of code in the RTL source code willnever be satisfied.
 4. The method of claim 2, wherein the one or morepredetermined properties include an assignment execution property thatrelates to checking whether each logical value can be assigned to avariable in the RTL source code through assignment operations appearingin the RTL source code.
 5. The method of claim 2, wherein the one ormore predetermined properties include a conflicting assignments propertythat relates to checking whether it is possible for a wire in thehardware design to be driven by multiple conflicting drivers.
 6. Themethod of claim 2, wherein the one or more predetermined propertiesinclude a constant value memory element property that relates todetermining whether a memory element in the hardware design will alwayshold a constant value.
 7. The method of claim 2, wherein the one or morepredetermined properties include a constant value variable property thatrelates to determining whether a variable in the RTL source code willalways hold a constant value.